fix(plugin-security): choose the platform-admin promotion target instead of sampling it — order the candidate read server-side and prefer the declared owner by os-trump · Pull Request #16863 · objectstack-ai/objectstack

os-trump · 2026-09-08T11:33:17Z

The single-posture first-boot promotion read sys_user with no orderBy and a cap of 50, then sorted that array client-side. So "the oldest authenticable user" meant the oldest authenticable user among whatever 50 rows the driver produced first — a sample sorted and reported as a global answer. And PLATFORM_OWNER_EMAIL_ENV, imported into that same file, was read only on the walled branch, so a deployment that had declared its owner could still have someone else promoted.

Both halves land together, per triage's ruling: ordering alone still promotes someone the operator never chose, and honouring the declaration alone leaves the no-declaration path sorting a truncated unordered sample.

Clause-②: yes — bootstrapPlatformAdmin is re-exported by name from plugin-security/src/index.ts:33 and the diff adds basis?: 'declared-owner' | 'oldest-authenticable' to its returned object, so the published .d.ts gains a key on a published payload.

The maintainer ruling this round executes

Decision batch #100, 2026-09-08, recorded on #16682 (comment 5587754690). It supersedes the Choice 4A sentence "single never reads OS_PLATFORM_OWNER_EMAIL" for this one point, and it settles the two findings the contract review held for a maintainer:

F3 — the declared owner decides the single promotion. The rest of Choice 4A (platform-admin re-anchor L4 (plugin-security): bootstrap stops granting under walled postures; explain reports config-derived standing; deprecation log for legacy grants #11974) stands: retiring the walled write must not retire the single one, and the over-denial invariant (adminPromoted === true with a grant row minted) stays pinned. The re-authored pin in bootstrap-platform-admin-walled-owner.test.ts now quotes that ruling, where the previous revision quoted the triage seat's — which was exactly the reviewer's F3 objection.
F4 — verification is a REQUIREMENT on the declared-owner leg, not a preference. A row is the declared owner only when all four hold: it holds the declared address, isHumanUser, it has a sys_account, and email_verified === true. Any miss refuses — zero grant rows, a warning naming the variable and the address — and there is no fall-back to oldest-authenticable while a declared address exists. The earlier "verified matches rank ahead of unverified ones" ordering is ruled moot; that bullet and its code are gone.
Accepted cost, stated by the ruling: a single deployment whose declared owner has not verified their email gets no platform admin at first boot until they do, loudly. It replaces a silent wrong promotion. The changeset says this too.

Measured, on this branch, both drivers

113 seeded sys_user rows, 7 holding credentials, the intended owner inserted first with the oldest created_at and an id that collates last, OS_PLATFORM_OWNER_EMAIL=admin@objectos.ai:

driver	the 50-row window	promoted BEFORE	promoted AFTER
memory (`InMemoryDriver`)	`window[0] = usr_zzz_owner` (insertion order)	`admin@objectos.ai`	`admin@objectos.ai`
sqlite (`SqlDriver`, the default)	`window[0] = usr_ats_c001` — the owner is not in the window at all (id order)	`candidate001@mail.example`	`admin@objectos.ai`

Re-measured with OS_PLATFORM_OWNER_EMAIL unset as well (the pure ordering leg): before, the same split; after, admin@objectos.ai on both drivers, basis: oldest-authenticable. The raw unordered 50-row window is still driver-shaped after the change — that is a fact about the drivers, and the file pins it as an anti-vacuity case. What is no longer driver-shaped is the answer.

What changed

The read is ordered where the driver can see it — created_at ascending with id as tie-breaker (seeded populations routinely share one timestamp, and among ties an unordered read is exactly the sample-dependent answer this fixes). There is deliberately no client-side re-sort left behind: one would re-rank the returned page and keep the guard passing if the ordering were ever lost again.
The declared owner is asked first, and must be a VERIFIED holder — a declared, authenticable, human, email_verified holder of an OS_PLATFORM_OWNER_EMAIL address is the target. isHumanUser still applies, so a declared address on a role: 'system' row is not a route to the grant.
A declared owner who cannot sign in, or has not verified, REFUSES — reason: 'declared_owner_not_authenticable' or 'declared_owner_not_verified', a warning naming the variable, the addresses and which half is missing, and no grant row at all. No silent fall-back to whoever happens to be oldest; that is the outcome the card is about.
Verification landing is a replay trigger again, narrowly. shouldReplayBootstrapFor admits a sys_user update touching email / email_verified under single — but only while an owner is declared. That is the one configuration in which such a write can change this function's answer, and it is what makes the ruling's "the replay predicate promotes as soon as verification lands" true rather than aspirational. platform-admin re-anchor L4 (plugin-security): bootstrap stops granting under walled postures; explain reports config-derived standing; deprecation log for legacy grants #11974 narrowed this arm away on the stated grounds that "single promotes the oldest authenticable human and never reads email/email_verified" — the ruling makes that clause false for exactly this configuration and for no other, so with no owner declared the narrowing is untouched.

The cap's disposition

Replaced, not merely raised, and never silent again. The bare 50 becomes PLATFORM_ADMIN_CANDIDATE_PAGE_SIZE = 200 walked oldest-first with a hard PLATFORM_ADMIN_CANDIDATE_SCAN_CEILING = 5000.

A ceiling is kept rather than dropped because this pass re-runs on every sys_user / sys_account insert until an admin exists (shouldReplayBootstrapFor), so an unbounded scan would be a per-sign-up full-table read on exactly the deployments that have not been promoted yet.
The difference from the old constant is the orderBy: an ORDERED page holds the OLDEST rows, which is exactly the set the age rule ranks, so truncation can only bite when every one of the oldest 5000 humans is non-authenticable. The unordered 50 could drop the answer on a 51-row install.
Reaching the ceiling WARNS, naming the number examined. Both constants are exported so the guard reads the same numbers the selection does rather than restating them.

The upgraded log line — exact text

Prefix unchanged (existing readers match on it); the basis and the pool are appended, and repeated in meta as basis / candidatePoolSize / userId for structured sinks. The returned report carries basis too.

[security] first user promoted to platform admin: admin@objectos.ai — basis: declared-owner; candidate pool: 1 address(es) declared in OS_PLATFORM_OWNER_EMAIL, 1 matching human user row(s)
[security] first user promoted to platform admin: admin@objectos.ai — basis: oldest-authenticable; candidate pool: 113 human user row(s) examined oldest-first by created_at

Truncation warning:

[security] the platform-admin candidate scan stopped at its ceiling of 5000 oldest sys_user row(s) and none of them can authenticate — rows beyond that point were NOT examined, so this deployment may hold a promotable human the boot did not see. Promote the intended administrator explicitly by setting OS_PLATFORM_OWNER_EMAIL.

Landing order relative to PR #16805 (F2)

scripts/engine-double-contract.pinned.json is a shared ledger, and open PR #16805 regenerates it too. It is not a single-writer block: SINGLE_CLAIM_PATHS declares .objectui-sha only, and check:single-claim-paths is green on this PR. What it is, is a regenerate-on-the-merged-tree obligation, and it is order-independent: whichever of the two lands second re-merges origin/main and re-runs node scripts/check-engine-double-contract.mjs --write on the merged tree, then commits whatever that produces. This branch has just discharged its half — #16592 and #16730 had already moved the file from 3845 to 3875 lines since the old merge base, origin/main is merged in here, and the regeneration on the merged tree reports 0 added or grown, 0 lost with the file at 3880 lines (main's 3875 plus this PR's 5 rows for the two new doubles). Nothing here needs #16805 to land first.

验收备注

Triage's rubric, copied, each condition with its evidence. All in packages/plugins/plugin-security/src/bootstrap-platform-admin-promotion-selection.test.ts (25 runtime cases) unless noted.

卡面给的回归测试形状原样采用 — seed 50-plus users with the intended owner sorting last by id and first by created_at, then assert the same user is promoted across driver row orders. ✅ The 113-row fixture is the card's, verbatim. ⚠️ The literal "memory AND sqlite" arm is a declared deviation — see the section below. What is pinned instead covers strictly more orders: three natural orders (AS_RETURNED, INSERTION, REVERSED), all on the real engine over the real better-sqlite3 driver, plus a case asserting all three agree. An anti-vacuity case proves the unordered 50-row window really does hide the owner on the real driver, so the file cannot pass for a reason unrelated to the repair.
声明 owner 的腿单独一条 — OS_PLATFORM_OWNER_EMAIL set to a user that is neither the oldest (its created_at is the newest of 113) nor in the first 50 rows (its id collates last), and which is the population's one verified row; asserted promoted under all three orders, with basis: declared-owner, and explicitly not the oldest authenticable human. ✅
阴性对照必测:
- 未设 OS_PLATFORM_OWNER_EMAIL 时回落到最老的可认证用户,且两驱动一致 — a fixture deliberately different from condition 1, where the oldest authenticable row is not the id-last row, so "oldest wins" and "the owner happens to sort last" are separated. Same answer under all three orders. ✅
- plugin-security promotes the OLDEST human sys_user row, so an app that seeds a people directory grants platform admin to a row nobody can log in as #14348 修的那条仍然成立 — two cases. The two oldest rows are credential-less directory rows and the only login is newer than both: the login is promoted, under all three orders — so an implementation that simply took min(created_at) fails here while condition 1 stays green. And a 60-row population where nobody can authenticate promotes nobody (no_authenticable_user, zero grant rows, and no warning, because that population is far under the ceiling). ✅
- 设了 OS_PLATFORM_OWNER_EMAIL 但该邮箱没有可用账号 — two sub-cases, no sys_user row at all and a verified row with no sys_account. Both refuse: declared_owner_not_authenticable, a warning naming the variable, the address and the phrase "NOT falling back to the oldest", and zero grant rows written. ⛔ No silent fall-back. ✅
- Extra, not asked for but adjacent: the reserved fork (plugin-security promotes the OLDEST human sys_user row, so an app that seeds a people directory grants platform admin to a row nobody can log in as #14348 case D) re-asserted against the new selector — an existing unscoped grant still short-circuits to already_have_admin before any selection runs, so a declared owner cannot re-point an existing platform admin. ✅
cap 的处置写进 PR — see "The cap's disposition" above. Any limit that remains warns on exceed, pinned in both directions (a population over the ceiling warns naming it; one inside it produces no such warning). ✅
日志升级 — exact text above; three cases pin the basis, the pool, the meta fields, and that the published prefix still matches. ✅
⛔ 不要改 :426 那处精确读 — untouched. git diff over the whole change contains no edit to that line (it now sits at :491, byte-identical). ✅

The ruling's pins, in both directions

unverified declared holder ⇒ declined, zero grant rows — with NOBODY verified, the declared-owner leg REFUSES (declared_owner_not_verified, grants() empty, warning naming the variable, the address, VERIFIED and "NOT falling back to the oldest"). This case is the re-authored predecessor of CONTROL: with nobody verified, the oldest holder of the declared address wins, which asserted precisely the outcome the ruling refuses.
verified declared holder ⇒ chosen — among rows holding the declared address, only the VERIFIED one is eligible, plus the three-order declared-owner arm and the walled-owner suite's over-denial guard.
replay chooses after verification — the refusal LIFTS the moment verification lands: the first pass refuses with zero grant rows, an email_verified update lands, the replayed pass promotes the same row with basis: declared-owner. The trigger predicate's own half is pinned beside its producer in bootstrap-platform-admin-walled-owner.test.ts (fires on the verifying update once an owner is declared; still does not fire with none declared, nor under a walled posture, nor for a name-only update, nor on sys_account).
the existing declared_owner_not_authenticable cases are kept — both of them, unchanged in reason code. Authenticability is asked before verification precisely so plugin-security promotes the OLDEST human sys_user row, so an app that seeds a people directory grants platform admin to a row nobody can log in as #14348's refusal keeps its own name and its own pins, and the fixture for the no-sys_account case is now verified so it isolates that axis alone.

F5 — the ordering guard now crosses a page boundary

The card's 113-row fixture fits inside one PLATFORM_ADMIN_CANDIDATE_PAGE_SIZE page, so it catches a lost orderBy only because there is no client-side re-sort left in the selection; a future defensive .sort() over the returned page would put every one of those cases back to green with the ordering gone. Added: one case at PLATFORM_ADMIN_CANDIDATE_PAGE_SIZE + 1 rows with the owner's id collating last, so an unordered read puts the owner on page two — outside anything a page-local re-sort can reach — while page one already holds an authenticable row for the loop to stop on. It fails on a lost orderBy whether or not a re-sort is reintroduced, and it carries its own anti-vacuity assertion that the population really does exceed one page.

F6 — the refusal warning re-emits, and that is accepted

With the variable set and the owner not yet promotable, every sys_user / sys_account insert (and now the verifying update) replays the pass and re-emits the full refusal warn — one warning per replay until the owner appears. Accepted, deliberately unlatched, and said so in the changeset: a reportLegacyPlatformAdminGrant-style once-per-process latch would silence the one line that tells a fresh operator why their deployment has no administrator, on exactly the boots where they are still reading the log. The cost is repetition in a log nobody is paging; the cost of the latch is a silent, permanently admin-less install.

F8 — untouched

Whether the literal two-driver test arm is wanted remains the maintainer's open question; it is not attempted here.

Declared deviation: the memory-driver arm is measured, not pinned

Condition 1 asks for the assertion on the memory driver and sqlite. @objectstack/driver-memory cannot be imported into this suite, for two reasons that are each outside a repair's authority:

Declaring it needs packages/plugins/plugin-security/package.json — claimed by open PR fix(plugin-security)!: evaluate the insert-side RLS check on the row that will be stored, after beforeInsert #16805 under the single-writer rule, which the dispatch names as a stop-and-report.
Independently, every declaration of that package in this repo must be disposed of in scripts/driver-memory-census.ledger.json, and a test consumer's only fitting axis is ruled-permanent, which the ledger states is "a maintainer ruling and lives in ruledConsumers; nothing else may claim it." The gate's own header says a third arrival "is now refused at the gate".

So the real memory-driver readings are in the table at the top of this PR — taken out-of-tree on this branch, before and after, and reported here rather than pinned. What the suite pins in their place is the property those two drivers were standing in for, over more orders than they produce between them, with the un-permuted arm being an ordinary real-driver run. If the maintainer wants the literal two-driver arm, it needs the ledger entry and the manifest edit, and both are theirs to make.

The facade is honest by construction: it permutes a result only when the query carried no orderBy — which is precisely the freedom a driver has there — and forwards an ordered query verbatim, returning the real SQL engine's rows untouched. It never sorts. So a fix that sent orderBy to a driver that ignored it would still be caught.

The re-authored pin, now backed by a maintainer ruling

bootstrap-platform-admin-walled-owner.test.ts carried a case asserting the exact behaviour this change reverses:

it('never consults the owner-email variable: a declared owner does NOT redirect the single-org promotion')

It is #11974's over-denial guard, and what it guards is unchanged: retiring the WALLED write must not retire the single one — adminPromoted === true with a grant row actually minted, still asserted. What changed is the incumbent it happened to snapshot alongside that invariant, and the file header's "byte-for-byte" wording.

The previous revision of this PR re-authored that case quoting the #16682 triage seat's ruling, and the contract review was right to refuse it (F3): a pin recorded under a maintainer ruling cannot be rewritten under a seat's. The quotation in the test is now the maintainer ruling of 2026-09-08 (batch #100) that resolved it, and the comment says in as many words which quotation it replaced and why.

Security boundary

This narrows who receives admin_full_access, which is the ruled direction. Three things worth naming rather than leaving to be found:

A grant is now written in one case where none was before: a promotable human outside the old 50-row window is now found. That is a false negative being repaired, not a new grantee class — the policy for the no-declaration leg ("the oldest human that can authenticate, and only when no admin exists") is unchanged, and plugin-security promotes the OLDEST human sys_user row, so an app that seeds a people directory grants platform admin to a row nobody can log in as #14348's rule is preserved exactly.
The one direction that was NOT a narrowing is now closed. The review's F4 measured it: a legitimate human registers first, then an attacker registers the declared address unverified; under a preference the attacker was promoted, and because sys_user.email is UNIQUE on the SQL family the real operator could not even coexist to outrank them. Under the ruling that squat is not a candidate at all — the leg refuses and nobody is promoted. Every declared-owner outcome is now a strict narrowing of the incumbent.
packages/cli's os meta resync calls this function and therefore inherits the declared-owner rule, verification requirement included. Intended, and consistent.

Verification

Final head ed6d4b2a85, an ordinary merge commit of origin/main (merge base dd2fd2003; ⛔ no history rewriting). Every number below was taken on that commit — git rev-parse --short HEAD = ed6d4b2a85 at the time of the runs.

pnpm --filter @objectstack/plugin-security exec vitest run over the three suites this change touches (bootstrap-platform-admin-promotion-selection.test.ts, bootstrap-platform-admin-walled-owner.test.ts, security-plugin.test.ts) — 3 files, 291 tests, all passing.
pnpm --filter @objectstack/plugin-security typecheck — clean.
pnpm --filter @objectstack/plugin-security test — 103 files, 1928 tests, all passing (1925 before this round; +3 is exactly the two cases added to the selection suite and the one added to the walled-owner suite).
pnpm lint — the full repo-wide eslint . --no-inline-config, exit 0 over 6395 files, 0 errors and 0 warnings (--format json, counted from its own output). Not narrowed, so no narrowing evidence is owed.
Derived gate union: 67 families, 67 run, 0 NOT-MEASURED, 0 UNRUN (node scripts/pm/dispatch-gates.mjs --ran, reconciled against the same derivation, re-derived after a fresh git fetch origin main and byte-identical). 64 exit 0. Zero findings (exit 1). The three non-zero are all exit 3, PREREQUISITE NOT MET — check:dual-build-cjs-loads, check:i18n and check:type-check-debt each require a full workspace build that CI does before them, and each says in its own words that this is "NOT a pass" and nothing was measured.
node scripts/check-engine-double-contract.mjs --write on the merged tree — 775 (file, verb) row(s), 0 added or grown, 0 lost and 6 seam row(s), 0 added or grown, 0 lost; the ledger is at 3880 lines and git status is clean, i.e. the merge already carried both sides.
node scripts/pm/check-clause2-carriers.mjs --pair 16863 — exit 0, "the clause-② declaration is readable in the fixed spelling and both carriers agree".
needs:contract-review verified present on both carriers by read-back (PR fix(plugin-security): choose the platform-admin promotion target instead of sampling it — order the candidate read server-side and prefer the declared owner #16863 and card plugin-security: the first-user promotion picks the oldest authenticable user from an UNORDERED 50-row sys_user window, so on the default driver a seeded job seeker became platform admin and owned every seeded row #16682). The PR stays draft: maintainer-merged, never enqueued and never auto-merge-armed.
Governed surfaces (docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md): none touched, so no maintainer-speed-read section is owed here.

Ablation — this round's two enforcement points, each proven able to fail

⚠️ Both legs were run on a committed tree, and both restore from HEAD. The suite imports ./bootstrap-platform-admin.js — a sibling module inside the same package — so vitest resolves the subject to src/, not to a built dist/: no rebuild is involved in these legs and the dist preflight does not apply to them. Each leg proved its mutation reached disk before running anything (anchor grep -cF 1 to 0, injected marker 0 to 1, and git hash-object differing from the HEAD blob 73543200badc1861fedeecea599dbb8dd1fdcd6d), and each restore is proven, not assumed (blob back to that exact hash and an empty git diff HEAD), under a trap 'restore' EXIT INT TERM naming a restore function, with absolute paths throughout.

ablation	mutation	result
A5 — the ruled verification requirement	disable `if (!isEmailVerifiedUserRow(row)) continue;` on the declared-owner leg	3 RED of 25 — including `the refusal LIFTS the moment verification lands`
A6 — server-side ordering	drop `OLDEST_FIRST` from the leg-2 candidate read	4 RED of 25 — including `with OS_PLATFORM_OWNER_EMAIL unset the fallback holds, identically under every order`

The capture was tail-bounded, so only the last FAIL line of each run is quoted above; the failure COUNTS are vitest's own summary line. The previous round's A1–A4 were taken on head 141876814, before this ruling changed leg 1: A1 (ordering) is superseded by A6 in a stronger form, A2's subject (the declared-owner leg) has been re-authored and is superseded by A5, and A3 (truncation warning) and A4 (log line) cover code this round did not touch.

Out of scope, filed

plugin-security: the already_have_admin short-circuit reads sys_user_permission_set with an UNORDERED cap of 50, so an existing unscoped platform admin can be missed and a SECOND one minted #16861 — the same defect class on the other read in this function: already_have_admin reads sys_user_permission_set with an unordered cap of 50 and applies the deciding !organization_id predicate client-side, so on an install with 50-plus organization-scoped grants of admin_full_access the existing unscoped holder can be missed and a second unscoped admin minted. Not folded in: triage scoped this card to the promotion read, and repairing that one changes when the short-circuit fires, which is permission-boundary behaviour needing its own tests.
Noted, not filed: sys_user.email carries a UNIQUE index, so on the SQL family two rows can never hold one address — measured as SQLITE_CONSTRAINT_UNIQUE while writing the earlier tie-break's fixture, which is why the two duplicate-address cases run on a double. It is also the mechanism that made F4's squat unanswerable by preference, so it is now recorded in the source comment rather than only here.

Generated by Claude Code

…ead of sampling it The `single`-posture first-boot promotion read `sys_user` with no `orderBy` and a cap of 50, then sorted that array client-side. So "the oldest authenticable user" meant the oldest authenticable user among whatever 50 rows the driver produced first, and a client-side sort cannot notice: it sorts a sample and reports a global answer. Measured on 113 seeded users with the intended owner inserted first, holding the oldest created_at and an id that collates last: the in-memory driver returned it in row 1 and promoted it; the default sqlite driver returned id order, never saw it, and gave the unscoped admin_full_access grant — plus, through claimSeedOwnership, ownership of every seeded business record — to a seeded job-seeker persona. Same code, same config, same data. PLATFORM_OWNER_EMAIL_ENV was imported into this same file and read only on the walled branch, so a deployment that had declared its owner could still have somebody else promoted. Both halves land together: ordering alone still promotes someone the operator never chose, and honouring the declaration alone leaves the no-declaration path sorting a truncated unordered sample. - the candidate read carries orderBy created_at asc, id asc, and no client-side re-sort is left behind - a declared, authenticable, human holder of an OS_PLATFORM_OWNER_EMAIL address is preferred; verified matches rank ahead of unverified ones - a declared owner nobody can sign in as REFUSES loudly and promotes nobody, never falling back to whoever happens to be oldest - the bare cap 50 becomes a 200-row page with a 5000-row ceiling walked oldest-first, and reaching the ceiling warns with the number examined - the promotion log line and the returned report record the basis and the candidate-pool size Unchanged: no declaration still means promotion by age; a user nobody can authenticate as is still never promoted (#14348); an existing unscoped grant still short-circuits before any selection runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012zTkyNHJ7TkuN2oXtP5x37

…rst-user-promotion-selection

…ared engine-double contracts The three doubles the new selection guard introduces are brought up to the contracts the repo's gates enforce, and the pinned ledger is grown so it actually protects this file: - update() routes through assertEngineUpdateDispatch, so a fixture drifting to a call shape ObjectQL.update would refuse fails loudly (check:engine-double-contract) - find() applies the caller's limit AFTER the filter and by presence (check:objectql-double-limit) - the WHERE matchers refuse a $-combinator by name instead of reading it as a field and answering false (check:where-matcher) scripts/engine-double-contract.pinned.json gains the new seams via `--write`; the shrink-only baseline is untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012zTkyNHJ7TkuN2oXtP5x37

…rst-user-promotion-selection

github-actions · 2026-09-08T11:33:56Z

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-security, touching 11 documentable anchor(s).

10 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

content/docs/data-modeling/field-type-decision-tree.mdx (via email_verified (literal, a string literal in shouldReplayBootstrapFor))
content/docs/data-modeling/objects.mdx (via sys_user_permission_set (literal, a string literal in bootstrapPlatformAdmin))
content/docs/data-modeling/validation-rules.mdx (via sys_account (literal, a string literal in bootstrapPlatformAdmin))
content/docs/deployment/environment-variables.mdx (via sys_user_permission_set (literal, a string literal in bootstrapPlatformAdmin))
content/docs/deployment/self-hosting.mdx (via sys_account (literal, a string literal in bootstrapPlatformAdmin))
content/docs/permissions/authentication.mdx (via email_verified (literal, a string literal in shouldReplayBootstrapFor), sys_account (literal, a string literal in bootstrapPlatformAdmin))
content/docs/permissions/authorization.mdx (via sys_user_permission_set (literal, a string literal in bootstrapPlatformAdmin))
content/docs/permissions/delegated-administration.mdx (via sys_user_permission_set (literal, a string literal in bootstrapPlatformAdmin))
content/docs/permissions/permission-sets.mdx (via sys_user_permission_set (literal, a string literal in bootstrapPlatformAdmin))
content/docs/protocol/objectui/actions.mdx (via sys_account (literal, a string literal in bootstrapPlatformAdmin))

⛔ 5 release-owned page(s) also name something this change touched. These are read-only:

content/docs/releases/implementation-status.mdx (via sys_user_permission_set (literal, a string literal in bootstrapPlatformAdmin))
content/docs/releases/v13.mdx (via sys_user_permission_set (literal, a string literal in bootstrapPlatformAdmin))
content/docs/releases/v14.mdx (via sys_user_permission_set (literal, a string literal in bootstrapPlatformAdmin))
content/docs/releases/v16.mdx (via sys_user_permission_set (literal, a string literal in bootstrapPlatformAdmin))
content/docs/releases/v17.mdx (via tryFind (symbol, a top-level function), sys_account (literal, a string literal in bootstrapPlatformAdmin), sys_user_permission_set (literal, a string literal in bootstrapPlatformAdmin))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

2 anchor(s) matched too much of the corpus to be a work list: created_at (literal, 33 pages), sys_user (literal, 31 pages)
the SDK route bridge reached 60 of 216 client-bound route-ledger rows — the other 156 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 156: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 100 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 15 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json d127f9babce9d483ac4c053194360968e1c7ba0a → packageMentionDocs.

Which tree this was computed on

This run read content/docs from d54b3d70ae2723b45e7b075e8b646ae8755b6f41 — the merge of head ed6d4b2a85709cd8c7c0aa93c1e6d821e9a98053 into base d127f9babce9d483ac4c053194360968e1c7ba0a, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin d54b3d70ae2723b45e7b075e8b646ae8755b6f41 && git checkout d54b3d70ae2723b45e7b075e8b646ae8755b6f41
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin d127f9babce9d483ac4c053194360968e1c7ba0a ed6d4b2a85709cd8c7c0aa93c1e6d821e9a98053 && git checkout -B drift-repro d127f9babce9d483ac4c053194360968e1c7ba0a && git merge --no-ff ed6d4b2a85709cd8c7c0aa93c1e6d821e9a98053

node scripts/docs-audit/affected-docs.mjs --json d127f9babce9d483ac4c053194360968e1c7ba0a

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs d127f9babce9d483ac4c053194360968e1c7ba0a → pass the list as
args.docs, on the commit named under Which tree this was computed on.

os-zhuang · 2026-09-08T15:00:58Z

Contract review (`claude-fable-5-1`, isolated seat) — PR #16863 @ `141876814`

Verdict: CHANGES REQUIRED

Ruling implemented: yes — the PR implements exactly the triage ruling on #16682 (comment 5578557793, by os-zhuang, author_association MEMBER, self-described as 分诊席 — a triage seat, ⛔ not a maintainer ruling): 「裁定：修法 1 + 2 都做，同一个 PR，⛔ 不要只做 1」, the six 验收口径 conditions, and 「⛔ 不要改 :426 那处精确读」. Both halves land in one change; :426's exact read is byte-identical at head (:491, tryFind(ql, 'sys_user', { id: holder.user_id }, 1)). Condition 1's literal "memory AND sqlite" arm is a declared deviation (three row orders on the real sqlite driver instead); the reasons given (single-writer claim on package.json by #16805, driver-memory-census.ledger.json ruled-permanent is maintainer-only) are both true against the tree.

Governed paths touched: NO — the diff vs merge-base ce8bfc9d6 is exactly 5 files: .changeset/platform-admin-promotion-selection.md, packages/plugins/plugin-security/src/bootstrap-platform-admin.ts (+338/−46), …/bootstrap-platform-admin-promotion-selection.test.ts (new, 812), …/bootstrap-platform-admin-walled-owner.test.ts (±56), scripts/engine-double-contract.pinned.json (+5). None under docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md, content/docs/releases/**. It does NOT touch packages/plugins/plugin-security/package.json, tsconfig.json or vitest.config.ts.

Clause-②: yes. Derivation, on the diff and the repo's own rules, not the body:

bootstrapPlatformAdmin is re-exported by name from packages/plugins/plugin-security/src/index.ts:33; the diff adds basis?: 'declared-owner' | 'oldest-authenticable' to its return type ⇒ a new key on a published payload. references/contract-review.md is unconditional here: 「机械地板 claim 时可查树：新导出符号或已发布载荷上的新键恒 yes，直接锁契约复审档」. The PR's "optional and additive, so no consumer can be rejected" is a conformance argument, and the same file says 「conformance 类 ⛔ 不机械化」 — it does not move the floor. The PM seat's correction (5586852304) reached the same yes; this review confirms it independently.
The two new export consts are NOT reachable from the published entry point (named re-export, exports map publishes only .) — correctly out of scope.
check-widening-tells.mjs exit 0 is expected and carries no information here: its T1/T2 surface is SUSPECT_TIER_GLOBS (packages/spec/src/**), T3 is packages/spec/api-surface/*.json, T4 is three named registries. packages/plugins/** is on none of them — that green is "did not look".
The behaviour change itself (who receives admin_full_access) is NOT what makes this clause-② — SKILL.md:516 「运行时权限/安全行为变更不是条款②，归人工地板安全/权限边界类」 — it is what makes this maintainer-only (see F3/F4).
Changeset level implied: the changeset exists and grades @objectstack/plugin-security: patch. check-changeset-no-major.mjs's LEVEL axis (its header: a PR that declares clause ② "may not grade a package it grew patch"; maintainer ruling 2026-09-04 on finding(changeset): two independent contract reviews read the repo's own history to opposite bumps for "add an exported symbol to a published index" #15294: an additive widening of a published surface "takes AT LEAST minor") cannot see this package: PUBLISHED_SOURCE_PATH = /^packages\/([^/]+)\/src\// (:822) matches one segment, and this file is packages/plugins/plugin-security/src/… — [finding] The changeset LEVEL axis is blind to every NESTED package: packages/*/src/** matches one segment, so 51 of 74 workspace packages (all drivers/services/adapters) can pair Clause-②: yes with patch and stay green #16713 exactly. Check Changeset green on this PR is therefore "did not look", not "approved". ⇒ the changeset must be minor (F1).

Verification

Diff vs merge-base — 4 commits (2 substantive + 2 origin/main merges), file list as above; git diff --name-only filtered against the governed globs and the three fix(plugin-security)!: evaluate the insert-side RLS check on the row that will be stored, after beforeInsert #16805 config paths returns nothing.
Source change (bootstrap-platform-admin.ts): tryFind gains optional orderBy/offset and only puts them on the query when passed, so every pre-existing call site sends the same query. Leg 1 reads resolvePlatformAdminEmails() (memoized parser from @objectstack/core), queries sys_user by both spellings, filters normalizePlatformAdminEmail(row.email) === email + isHumanUser, sorts verified-first then byCreatedAtAsc, takes firstAuthenticable; refuses with declared_owner_not_authenticable and a warn when none. Leg 2 pages OLDEST_FIRST = [created_at asc, id asc]. Both legs run AFTER the already_have_admin short-circuit (:477 vs :754), which is unchanged.
The scan loop — for (offset = 0; offset < 5000 && !target; offset += 200): breaks on empty page, on target, on a short page; sets scanTruncated only when offset + page.length >= ceiling. Terminates in ≤ 25 iterations even against a driver that ignores offset. orderBy reaches the driver: query.orderBy is set when passed; ObjectQL engine.ts:415 whitelists orderBy/offset and :9376 parses each node with SortNodeSchema ({ field, order: 'asc'|'desc' } — the shape the diff sends); SqlDriver applies it at sql-driver.ts:9127/:14790 and its paging tie-breaker (id) is already the second key. The truncation warning fires only when no target was found AND the ceiling was hit — pinned in both directions by the synthetic cases (ceiling + page ⇒ warns; ceiling − page ⇒ silent). shouldReplayBootstrapFor is unchanged (sys_user/sys_account × create/insert × non-walled), so a declared owner whose login lands later is promoted on that insert's replay — leg 1 runs on every pass.
The re-authored pin (walled-owner.test.ts:461): the over-denial invariant IS still asserted — expect(r.adminPromoted).toBe(true) and expect(ql.grants()).toHaveLength(1); what moved is grants()[0].user_id from u_first to u_second plus basis === 'declared-owner'. Stated plainly: a pin that asserted a behaviour recorded under a maintainer ruling (platform-admin re-anchor L4 (plugin-security): bootstrap stops granting under walled postures; explain reports config-derived standing; deprecation log for legacy grants #11974 / Choice 4A — [Design] Re-anchor platform-admin: admin_full_access becomes a kernel metadata declaration; WHO holds it comes from env-configured verified emails — retiring the org-less row anchor #11663 comment 5404675670, 2026-08-25, 「接受你的建议，继续」; and the feat(plugin-security): walled bootstrap stops minting the platform-admin grant row; platformAdmin audit service; legacy-grant deprecation pointer (L4) #13514 contract-review PASS by zhuangjianguo, director seat, which recorded as verified 「single 晋升读最老 human、从不读 email/email_verified」) was rewritten under a triage seat's ruling of 2026-09-08. The dev named the collision honestly; it is not the dev's or the PM's to resolve.
Security, declared-owner leg without email_verified — measured against the diff, precisely:
- FROM (base, single, variable set or unset): the oldest authenticable human among an unordered 50-row driver window is promoted. An attacker who registers FIRST on an empty install is promoted; no config knowledge needed.
- TO (head, variable unset): same policy, now over the full ordered population — the attacker-who-registers-first is promoted exactly as before.
- TO (head, variable set): the attacker-who-registers-first is promoted ONLY if they hold the declared address; otherwise the pass refuses (nobody promoted) — a strict narrowing for that attacker.
- ⚠️ But there is one direction that is NOT a narrowing: a legitimate human registers first (address ≠ declared), then an attacker registers the declared address, unverified. FROM: the legitimate first user is promoted. TO: the attacker is promoted (basis: declared-owner), because verified-first is a tie-break that only helps when a verified holder EXISTS, and on the SQL family sys_user.email is UNIQUE so the operator cannot even register alongside the squat. The PR's "the set of winning attackers strictly shrinks" is false for this case; the price of the squat is knowing the declared address (env, but typically admin@<domain>). This is the walled derivation's named threat, answered by refusal there and by preference here. Maintainer's call (F4).
Tests — 19 literal it( in the new file; two sit inside for (const order of NATURAL_ORDERS) (3 orders) ⇒ 23 runtime cases, matching the claim. No .skip / .only / .todo / xit. ⛔ Not executed by this seat: this checkout has no node_modules and the suite needs the real better-sqlite3 driver, so a run is not cheap; the ablation table was reasoned from source instead. A1 (drop OLDEST_FIRST) reds under AS_RETURNED because sqlite's id order puts usr_ats_c001 (has an account) before usr_zzz_owner and there is no client re-sort — confirmed. A2/A3/A4 red on the assertions named. One structural gap in F5.
CI on the head — 37 check runs, 0 failures (all success or skipped); mergeable_state: clean; PR is draft: true. RULE 2: none of the 4 commits carries a Fixes/Refs/Part of trailer (the only card mention is prose (#14348) in a bullet); the "Part-of PR must not also close its card" job, which runs check-partof-closing-keyword.mjs over the commit list, is green. Advisory only.
plugin-security: the already_have_admin short-circuit reads sys_user_permission_set with an UNORDERED cap of 50, so an existing unscoped platform admin can be missed and a SECOND one minted #16861 — exists, open, bug/security/domain:services, and describes the already_have_admin read (sys_user_permission_set, unordered, cap 50, !organization_id applied client-side). Correctly filed out of scope.
Single-writer — measured on fix(plugin-security)!: evaluate the insert-side RLS check on the row that will be stored, after beforeInsert #16805's current file list (11 files): it modifies scripts/engine-double-contract.pinned.json, which this PR also modifies. Collision confirmed (F2).

Findings

F1 — blocking. Changeset graded patch while the PR is clause-② yes (new key basis on a published payload). The LEVEL axis is blind to this package (#16713), so no gate will catch it. Expectation: regrade .changeset/platform-admin-promotion-selection.md to "@objectstack/plugin-security": minor.

F2 — blocking for landing (not a defect in the diff). scripts/engine-double-contract.pinned.json is also modified by open PR #16805; under single-writer this PR cannot enter the queue until #16805 lands or the maintainer sequences them. Expectation: land after #16805 and re-merge origin/main, or the maintainer rules the order.

F3 — blocking; maintainer ruling required. A pin recorded under a maintainer ruling (Choice 4A, and the #13514 PASS's 「从不读 email/email_verified」) is reversed under a triage seat's ruling. The diff is consistent with the newer ruling; whether the newer ruling stands is not a seat decision. Expectation: maintainer confirms that under single a declared owner may decide the promotion (option A in the dev report), or reverses — in which case leg 1 is withdrawn and #16682 falls to fix 1 alone.

F4 — blocking; maintainer ruling required. The declared-owner leg does not require email_verified; item 5 above shows one non-narrowing direction (a squat of the declared address now outranks a legitimate older first user). Expectation: maintainer chooses A (as landed, preference only) or B (require verified on this leg; note UNIQUE email means B refuses until the address is reclaimed). Whichever is chosen, the changeset should state the threat and the answer in one sentence.

F5 — not blocking. The card-shape fixture is 113 rows, below PLATFORM_ADMIN_CANDIDATE_PAGE_SIZE = 200, so the whole population fits one page. The guard catches a lost orderBy today only because no client re-sort exists; a future "defensive .sort()" plus a lost orderBy would go green. The anti-vacuity case measures the OLD 50-row window, not the new page. Expectation: grow the card-shape population past the page size (e.g. 250) or add one case at PAGE_SIZE + 1 with the owner id-last.

F6 — not blocking. With the variable set and the owner not yet registered, every sys_user/sys_account insert replays the pass and re-emits the full refusal warn — one warning per sign-up until the owner appears. Expectation: consider a once-per-process latch like reportLegacyPlatformAdminGrant's, or accept and say so in the changeset.

F7 — not blocking. The PR body's "Clause ② derivation: no … needs:contract-review is therefore not hung" is stale: the label is on both carriers (PM correction 5586852304) and this review derives yes. Expectation: edit that section to yes with the basis reason so the body and the carriers agree.

F8 — advisory. The memory-driver arm deviation is reasonable given the ledger and single-writer constraints; whether the literal two-driver arm is wanted is the maintainer's (dev report open question 1).

Maintainer-only merge: yes — Clause-② yes on a security gate (who receives the unscoped admin_full_access grant), a pin recorded under a maintainer ruling rewritten under a triage-seat ruling (F3), and an accept-set direction on that gate the maintainer has not ruled on (F4). No governed path and no !/breaking marker; those are not the reason.

Generated by Claude Code

… address under `single` The declared-owner leg ranked verified rows ahead of unverified ones and promoted an unverified holder where no verified one existed. Because `sys_user.email` is UNIQUE on the SQL family, a squatter who registered the declared address first could not be outranked by the real operator, who could not hold a row at all. Verification becomes a requirement: a declared address without a verified, authenticable, human holder refuses with zero grant rows and a warning naming the variable, the address and which half is missing. `shouldReplayBootstrapFor` admits the verifying `sys_user` update again, but only under `single` with an owner declared — the one configuration in which such a write can change this function's answer. Also regrades the changeset to `minor` (clause-② yes: `basis` is a new key on a published payload) and adds a candidate-page-crossing ordering case. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018rzQyhLGC5iVs11V3TzRs5

…rst-user-promotion-selection

yinlianghui · 2026-09-09T03:25:54Z

维护者速读(终稿)— PR #16863 · #16682 · 只等你合并

事情。 单组织(single)部署首次启动时,平台管理员的提升原来是「随机抽样」:读 50 行 sys_user 不排序、再在内存里排,谁被提升取决于存储驱动(内存驱动提升了你指定的 owner,sqlite 提升了一个招聘 demo 里的求职者);而且 OS_PLATFORM_OWNER_EMAIL 在这条路上根本没被读。

改法(已按你 09-08 批 #100 的裁决 A 执行)。

声明了 owner ⇒ 只提升已验证邮箱的持有者;未验证或不能登录 ⇒ 拒绝、零授权、打警告,绝不回退到「最老的人」;验证一落地,replay 立即提升(谓词只在有声明时多认这一种写)。
没声明 owner ⇒ 按 created_at asc, id asc 让数据库排序,分页 200、上限 5000,触顶必警告;老行为不变。
授权日志多记「依据」与「候选池大小」,返回值多一个 basis 键(这就是 clause-② 的加宽,changeset 已按 minor)。

验证。 新增 25 个用例跑在真实引擎 + 真实 sqlite 上,两条消融各自变红;CI 33 项全绿(ed6d4b2a85);契约层复审 PASS(#16682 评论)。

为什么要你亲手合。 总监席裁定:这是安全门(谁拿到无范围的 admin_full_access)+ clause-② ⇒ 只能维护者合并;PR 保持 draft,squash 信息用 PR 正文。

接受的代价。 声明了 owner 但没验证邮箱的 single 部署,首次启动没有平台管理员,日志会一直提醒直到验证完成。

要你答的只有一个字:合不合?(是/否)

Generated by Claude Code

claude added 4 commits September 8, 2026 10:30

Merge remote-tracking branch 'origin/main' into claude/issue-16682-fi…

9c1cc75

…rst-user-promotion-selection

Merge remote-tracking branch 'origin/main' into claude/issue-16682-fi…

1418768

…rst-user-promotion-selection

github-actions Bot added size/xl documentation Improvements or additions to documentation tests tooling labels Sep 8, 2026

os-project-manager mentioned this pull request Sep 8, 2026

[finding] The empty-generator refusal reads Failed to load generator "": is not a valid JS file — a double space, because bundle-require concatenates an empty filepath #16359

Closed

os-trump mentioned this pull request Sep 8, 2026

plugin-reports: a non-member timezone silently discards a report schedule's cron and fires it on the interval cadence forever — and the create-time guard cannot see it #16291

Closed

os-trump mentioned this pull request Sep 8, 2026

plugin-security: the first-user promotion picks the oldest authenticable user from an UNORDERED 50-row sys_user window, so on the default driver a seeded job seeker became platform admin and owned every seeded row #16682

Closed

os-trump added the needs:contract-review label Sep 8, 2026 — with Claude

os-zhuang mentioned this pull request Sep 8, 2026

[PM seat] director(项目总监) — 🟢 os-zhuang（第 15 场）· ⏹️ 第 16–20 场已收班（第 20 场 = 总监契约复审 session_01Tep4AYXZvyBA7jsvne5KZV，收班 2026-09-09T07:20Z） #12708

Open

os-zhuang removed the needs:contract-review label Sep 8, 2026 — with Claude

os-trump mentioned this pull request Sep 8, 2026

plugin-audit's read-audit rows back-date created_at to the VIEW instant through an isSystem reliance the audit hook never honoured, so every batched sys_audit_log read row now gets the FLUSH instant #16829

Closed

os-musk mentioned this pull request Sep 8, 2026

finding: seven non-published sites still state the superseded readonly-on-INSERT contract as live — carded, not fixed, by the 2026-09-05 E3 ruling 「已发布必修,其余立卡」 (PR #15395 / #14147) #15819

Closed

os-trump added the needs:contract-review label Sep 9, 2026 — with Claude

yinlianghui mentioned this pull request Sep 9, 2026

[PM seat] domain:services — 🟢 os-trump · session_012zTkyNHJ7TkuN2oXtP5x37 · R25 · (consolidated-seat takeover of 09-09T01:4xZ withdrawn 06:3xZ — see brief) #6021

Open

os-trump mentioned this pull request Sep 9, 2026

The #3424 admin override has no Console control: a record stranded behind an unstaffed approval is releasable only through the API #16679

Closed

yinlianghui mentioned this pull request Sep 9, 2026

[finding] The NUMERIC column family diverges from driver-sql in both migration formats — driver real, generators numeric, and rating is real against integer #16318

Closed

Merge remote-tracking branch 'origin/main' into claude/issue-16682-fi…

ed6d4b2

…rst-user-promotion-selection

yinlianghui removed the needs:contract-review label Sep 9, 2026 — with Claude

yinlianghui requested review from hotlong and os-zhuang September 9, 2026 03:25

os-zhuang approved these changes Sep 9, 2026

View reviewed changes

os-zhuang marked this pull request as ready for review September 9, 2026 03:33

os-zhuang enabled auto-merge September 9, 2026 03:33

os-zhuang added this pull request to the merge queue Sep 9, 2026

Merged via the queue into main with commit 9b9581b Sep 9, 2026
44 checks passed

os-zhuang deleted the claude/issue-16682-first-user-promotion-selection branch September 9, 2026 03:58

os-trump mentioned this pull request Sep 9, 2026

plugin-security: the already_have_admin short-circuit reads sys_user_permission_set with an UNORDERED cap of 50, so an existing unscoped platform admin can be missed and a SECOND one minted #16861

Closed

yinlianghui mentioned this pull request Sep 9, 2026

skills(pm-dispatch): the single-writer set is what SINGLE_CLAIM_PATHS enumerates — said where the seat reads batch independence #17089

Merged

Navigation Menu

Uh oh!

fix(plugin-security): choose the platform-admin promotion target instead of sampling it — order the candidate read server-side and prefer the declared owner - #16863

fix(plugin-security): choose the platform-admin promotion target instead of sampling it — order the candidate read server-side and prefer the declared owner#16863
os-zhuang merged 6 commits into
mainfrom
claude/issue-16682-first-user-promotion-selection

os-trump commented Sep 8, 2026 •

edited by yinlianghui

Loading

Uh oh!

github-actions Bot commented Sep 8, 2026 •

edited

Loading

Uh oh!

os-zhuang commented Sep 8, 2026

Uh oh!

yinlianghui commented Sep 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

os-trump commented Sep 8, 2026 • edited by yinlianghui Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The maintainer ruling this round executes

Measured, on this branch, both drivers

What changed

The cap's disposition

The upgraded log line — exact text

Landing order relative to PR #16805 (F2)

验收备注

The ruling's pins, in both directions

F5 — the ordering guard now crosses a page boundary

F6 — the refusal warning re-emits, and that is accepted

F8 — untouched

Declared deviation: the memory-driver arm is measured, not pinned

The re-authored pin, now backed by a maintainer ruling

Security boundary

Verification

Ablation — this round's two enforcement points, each proven able to fail

Out of scope, filed

Uh oh!

github-actions Bot commented Sep 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📓 Docs Drift Check

Uh oh!

os-zhuang commented Sep 8, 2026

Contract review (claude-fable-5-1, isolated seat) — PR #16863 @ 141876814

Verification

Findings

Uh oh!

yinlianghui commented Sep 9, 2026

维护者速读(终稿)— PR #16863 · #16682 · 只等你合并

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

os-trump commented Sep 8, 2026 •

edited by yinlianghui

Loading

github-actions Bot commented Sep 8, 2026 •

edited

Loading

Contract review (`claude-fable-5-1`, isolated seat) — PR #16863 @ `141876814`